Это решение реализует функции мониторинга виртуальных десктопов, обнаружения аномалий и оптимизации VDI-инфраструктуры. О прошлой версии этого пакета 1.1 мы писали год назад.
Давайте посмотрим, что нового появилось в vROPs MP for Horizon 2.0:
1. Мониторинг служб и сессий Unified Access Gateway
Здесь появились следующие новые возможности:
Идентификация UAG с малой производительностью в контексте виртуальных машин и KPI сессий Horizon
Функции HTTP Health Check в рамках функциональности мониторинга доступности UAG
Просмотр производительности и доступности привязанного Connection Server
Вкладка UAG Summary дает детальную информацию, для которой теперь не требуется отдельный дэшборд
Также теперь появился новый дэшборд Unified Access Gateways:
2. Новые варианты использования для Horizon Connection Servers
Тут появились следующие нововведения:
Нахождение проблем с производительностью и доступностью серверов Connection Servers
Мониторинг доступности служб Connection Server: проверки Tomcat и HTTP Health Check
Обнаружение Connection Servers, не сбалансированных в плане сессий и вычислительных ресурсов
Вкладка Summary дает детальную информацию, для которой теперь не требуется отдельный дэшборд
Собственно, вкладка Summary выглядит так:
3. Метрики Horizon User Capacity и рекомендации по сайзингу
Они показывают рекомендации о том, стоит ли добавлять или уменьшать вычислительные ресурсы (vCPU и память):
4. Метрики Horizon VDI Pool Capacity и рекомендации по оптимизации
Для пулов виртуальных ПК мы теперь видим их емкость в разрезе различных ресурсов, а также рекомендации по изменению конфигурации пулов в целях оптимизации и баланса:
Пользователи продукта vRealize Operations Advanced / Enterprise, vRealize Suite, а также облачной подписки vRealize Cloud Universal могут включить пакет vRealize Operations Management Pack for Horizon 2.0 через vRealize Operations Marketplace.
За последние пару месяцев на сайте проекта VMware Labs вышло несколько обновлений утилиты vSphere Diagnostic Tool. Напомним, что это средство представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О первой версии vSphere Diagnostic Tool мы писали вот тут.
Основное назначение данной утилиты - дать администраторам быстрое средство траблшутинга, которое они могут использовать для первичной идентификации наиболее распространенных проблем. Если все проверки пройдут успешно, то дальше уже можно более глубоко изучать логи и проводить дополнительные тесты.
Давайте посмотрим, что нового появилось в vSphere Diagnostic Tool (сейчас актуальная версия 1.1.4) с момента ее последнего релиза:
Исправлены проблемы со спецсимволами в паролях
Тесты имеют таймаут 10 секунд, а ключ -f используется для пропуска таймаутов
Название проверки выводится еще до ее запуска
Проверка VC Disk Space Check теперь игнорирует раздел proc
Проверка VC Info Check теперь имеет приятный вывод и возможность вывода во внешний канал PSC
Улучшены проверки VC Core Check
Исправлено множество ошибок, связанных с обработкой паролей и сертификатов
Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).
Скачать утилиту vSphere Diagnostic Tool можно по этой ссылке.
Таги: VMware, Labs, Troubleshooting, Update, vSphere, vCSA, vCenter, Photon OS
Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:
Hardware for Use with VMware vSphere
ESXi and Virtual Machines
Guest Operating Systems
Virtual Infrastructure Management
Подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках.
Документ очень полезный, состоит из почти ста страниц и дает просто огромное количество полезной информации для администраторов, одной из главных задач которых является поддержание требуемого уровня производительности виртуальной среды.
Скачать Performance Best Practices for VMware vSphere 7.0, Update 3 можно по этой ссылке.
Компания Principled Technologies выпустила интересное сравнение производительности в контексте плотности размещения виртуальных машин на сервере (VM Density), которое показывает превосходство гипервизора VMware vSphere 7 Update 2 над открытой архитектурой Red Hat OpenShift версии 4.9.
Для тестирования использовались виртуальные машины с полезной нагрузкой SQL Server. С точки зрения оборудования использовался кластер из 5 одинаковых серверов HPE ProLiant DL380 Gen 10, где были размещены ВМ, также для OpenShift дополнительно использовались еще 3 хоста как управляющие узлы.
Первый результат теста - это максимальное число активных виртуальных машин на один узел, которые можно было разместить при обеспечении определенного уровня производительности SQL Server. Тут результат 14-30 в пользу платформы VMware vSphere 7 Update 2:
Также создавали простаивающие виртуальные машины и смотрели, какое их максимальное количество можно разместить на одном хосте, тут тоже vSphere далеко впереди:
В исследовании отдельно подчеркивается, что VMware vSphere имеет также следующие преимущества:
Механизм обеспечения высокой доступности VMware HA работает более эффективно и проще настраивается
Рутинные задачи (Day-2) на платформе VMware vSphere выполнять удобнее и быстрее
Для хостов ESXi можно делать апгрейд хостов без их перезагрузки
Продолжаем рассказывать о продукте NAKIVO Backup & Replication, предназначенном, в основном, для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V. Но сегодня мы расскажем еще об одной полезной функции этого продукта - бэкап физических серверов, не состоящих в виртуальной среде.
Многие из вас знакомы с решением VMware App Volumes, которое предназначено для распространения готовых к использованию приложений посредством подключаемых виртуальных дисков к машинам. В 2014 году компания VMware купила этот продукт вместе с компанией CloudVolumes, которая на тот момент выпускала решение, позволявшее распространять виртуализованные приложения VMware ThinApp в виде дисков VMDK, которые можно подцепить к виртуальным машинам, предоставляя тем самым ее пользователям доступ к данному приложению...
Как знают администраторы VMware vSphere, сервер управления виртуальной инфраструктурой vCenter умеет исполнять задачи, создаваемые различными пользователями, в параллельном режиме в целях ускорения работы. Их может быть несколько сотен, а число одновременных сессий от пользователей в теории может достигать двух тысяч.
Не так давно компания VMware выпустила интересное видео "Extreme Performance Series: vCenter Concurrency", где рассказывается о различных аспектах работы этого механизма:
Также вам могут оказаться полезными следующие статьи о vCenter и его механизме параллельно исполняемых задач, материал из которых релевантен обсуждаемому в видео выше:
Все необходимые функции для работы с API по управлению сертификатами были добавлены в PowerCLI версии 12.4 в конце прошлого года, и теперь можно полноценно управлять ими с помощью сценариев.
Вот какие командлеты используются в VMware vSphere 7 (некоторые из них доступны и в более ранних версиях платформы) для получения информации о сертификатах, их добавления и удаления:
Для работы с Trusted Certificate Store
можно использовать командлет Get-VITrustedCertificate, который проверяет корневые сертификаты на сервере vCenter Server и/или на присоединенных хостах ESXi (параметры issuer, expiration date, serial number и другие). Вот пример, как проверить хранилища сертификатов на серверах на предмет устаревших сертификатов:
#Check the trusted certificate store of the vCenter and all connected ESXi servers for expired certificates
Get-VITrustedCertificate | Where-Object { $_.NotValidAfter -lt (Get-Date) }
Если мы хотим добавить сертификат или цепочку сертификатов в центр сертификации (certificate authority), который мы используем для хранилища сертификатов, можно использовать командлет Add-VITrustedCertificate:
#Read the certificate or certificate chain from a .pem file
$trustedCertChain = Get-Content "C:\Users\jdoe\Downloads\ca-chain.cert.pem" -Raw
#Add it to the trusted certificate stores of the vCenter and the ESXi servers
Add-VITrustedCertificate -PemCertificateOrChain $trustedCertChain
Также есть командлет Remove-VITrustedCertificate для удаления доверенных сертификатов, которые нам больше не нужны (используйте ее очень осторожно, ведь можно случайно удалить используемый сертификат). В интерфейсе этой функции нет, чтобы администратор случайно не удалил нужные сертификаты из цепочек. Вот как это работает:
2. Управление SSL-сертификатами компьютеров на сервере vCenter Server
Если у нас есть несколько компьютеров, с которых администраторы получают доступ к vSphere Client, и мы хотим, чтобы сертификаты принимались по умолчанию, мы должны заменить сертификаты на сгенерированные доверенным центром сертификации (trusted certificate authority).
Сначала с помощью этого командлета проверяем текущий сертификат машины vCenter:
Get-VIMachineCertificate -VCenterOnly
После этого создаем запрос на подписку сертификата (certificate signing request, CSR) для vCenter Server. Можно использовать командлет VIMachineCertificateSigningRequest:
После того, как мы получим файл сертификата от центра сертификации, мы можем заменить сертификат машины vCenter с помощью командлета Set-VIMachineCertificate:
Перед установкой SSL-сертификата машины мы должны убедиться, что корневой сертификат нашего CA добавлен в хранилище сертификатов vCenter Server. Помните, что замена сертификата вызовет перезагрузку vCenter.
3. Управление SSL-сертификатами машин для серверов ESXi
Если мы хотим управлять сертификатами полностью самостоятельно, нужно также заменить и сертификаты хостов ESXi. Рабочий процесс в этом случае выглядит несколько сложнее. Сначала нужно изменить настройку режима управления сертификатами хостов ESXi на custom на сервере vCenter и перезагрузить его.
После этого нужно сгенерировать CSR-запрос для сервера ESXi. Шаг похож на оный для vCenter Server, только нужно будет указать параметр CommonName. Это должно быть FQDN-имя хоста или его IP-адрес. Убедитесь, что CommonName совпадает с идентификатором, по которому вы добавляли этот хост в vCenter.
Так же, как и для vCenter, перед установкой сертификата машины нужно убедиться, что корневой сертификат нашего центра сертификации добавлен в доверенное хранилище сертификатов на хосте ESXi и других серверах, с которыми он взаимодействует, то есть остальные хосты ESXi и vCenter.
$vmhost = Add-VMHost -Name <ESXi host's FQDN> or <ESXi host's IP address> `
-Location (Get-Datacenter "My Datacenter")`
-User "My User" `
-Password "My Password"
В начале февраля компания VMware сообщила, что убрала из списка доступных загрузок дистрибутив своего средства vCenter Converter, которое предназначено для перенесения физических и виртуальных машин с различных платформ в среду VMware vSphere.
Сделано это было из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивается - последний релиз VMware vCenter Conterter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет до этого. Поддержка этого продукта закончилась в декабре 2019, а последний раз о нем мы упоминали вот тут. Выглядел он тогда так:
Напомним, что для корпоративной инфраструктуры есть средство VMware HCX Enterprise, которое предназначено для переноса виртуальных машин из локального датацентра в облачную инфраструктуру сервис-провайдеров VCPP или публичных облаков, но вот для P2V-миграции внутри датацентра решения от VMware больше нет.
Между тем, VMware заявляет, что работа над новым VMware vCenter Converter ведется, и обязательно будет выпущена его полностью переработанная версия. Сроков пока не называют, поэтому, скорее всего, случится это не раньше конференции VMworld 2022, которая пройдет осенью.
Как знают многие администраторы, еще в прошлом году в ESXi 7 Update 2 компания VMware стала убирать различные настройки из основного конфигурационного файла esx.conf. Кстати, и не только оттуда. Например, раньше глобальные настройки FDM (он же HA - High Availability) хранились в файле /etc/opt/vmwware/fdm/fdm.cfg. Теперь их там тоже нет - они переехали во внутреннее хранилище ConfigStore, работать с которым нужно с помощью утилиты командной строки configstorecli.
То же самое произошло и с NTP - теперь настройки времени, хранящиеся в /etc/ntp.conf (для NTP) и /etc/ptp.conf (для PTP), недоступны для редактирования через файлы конфигураций. Кстати, если вы не знаете, чем NTP отличается от PTP, у нас есть отличная статья на эту тему (а вот тут - о поддержке PTP в vSphere 7 Update 2).
Более того, теперь все файлы каталога /etc помечены как только для чтения и не сохраняют своих изменений при перезагрузке!
Так что работать с большинством настроек теперь нужно через ConfigStore. В частности, для NTP и PTP есть 2 основных команды, которые взаимодействуют с ConfigStore для конфигурации времени:
Получение настроек времени
# esxcli system ntp get
# esxcli system ptp get
Установка настроек времени
# esxcli system ntp set
# esxcli system ptp set
Если вы хотите узнать список всех конфигурационных файлов, которыми теперь заведует ConfigStore, можно выполнить следующую команду в консоли ESXi:
Весной 2020 года компания VMware объявила об интеграции своей платформы для виртуализации и доставки настольных ПК предприятия Horizon с решениями компании ControlUp, которая является технологическим партнером VMware.
В ноябрьском обновлении VMware Horizon 2111, о котором мы писали вот тут, эта интеграция уже реализована. Суть данных интеграций - дать администраторам набор инструментов для отладки подключений и производительности виртуальных ПК пользователей, который все чаще стали работать из дома, а значит в очень неоднородной среде с точки зрения скорости и стабильности соединения.
Первый продукт, который поддерживает новый релиз - это решение Scoutbees. Оно позволяет мониторить доступность сетевых ресурсов (десктопы, приложения, компоненты VMware UAG и DNS и прочее) и оповещать администраторов о проблемах, с которыми сталкиваются пользователи. Путем анализа проблем (они могут и не подтвердиться на стороне клиента) - администраторы предпринимают определенные действия по улучшению соединений.
Scoutbees осуществляет синтетический мониторинг, то есть посылает запросы к удаленному ресурсу и получает не только ответ, но и метрики key performance indicators (KPI), которые могут использоваться для целей прогнозирования и анализа подозрительных активностей. Для анализа инфраструктуры виртуальных ПК вы можете подключить мониторинг компонентов VMware Unified Access Gateway (UAG) и Horizon Connection Server. Также решение может проактивно тестировать доступность веб-приложений, сетевых служб, DNS-серверов, файловых шар, принтеров и других ресурсов.
Scoutbees - это облачный SaaS-продукт, который можно начать использовать прямо из браузера, без необходимости развертывания в своей инфраструктуре. Есть также и онпремизная его версия.
Вторая интеграция - это возможность использования решения Remote DX для мониторинга компьютеров удаленных пользователей. Это средство позволяет удаленно собрать информацию о скорости и качестве Wi-Fi соединения, а также производительности подключения пользователя к интернету. Вследствие этого администраторы могут делать скоринг пользователей по этому параметру и решать возникающие проблемы пользователей. Вот, например, у пользователя задержка (latency) составляет 219 миллисекунд между его устройством точкой доступа Wi-Fi. А между Horizon Client и его десктопом Horizon задержка равна 362 миллисекундам.
С использованием Remote DX администратор видит, что у пользователя относительно сильный сигнал Wi-Fi на уровне 81% и round-trip time (RTT), которое для гугла составляет 244 миллисекунды. А вот от роутера до гугла пользователь получает задержку 25 мс - это значит проблема в связи между устройством пользователя и его роутером.
По умолчанию решение Remote DX отображает только основные метрики, но собирает оно все, и их можно вывести для отображения в таблице:
Также можно использовать ControlUp Real-Time Console для вывода информации информации в колонках в соответствии с заранее сделанными пресетами:
Самая главная метрика здесь - это Client Device Score, которая дает администратору понять, все ли в порядке у пользователя с интернетом и доступом к удаленному десктопу в целом. Также есть и другие колонки, которые помогут вам понять, в чем дело, если у пользователя есть проблемы:
Более подробно об интеграции VMware Horizon и Remote DX рассказано вот в этой статье.
Некоторые из вас, вероятно, знают такой сайт virten.net, где в свое время публиковалось много интересных технических статей об инфраструктуре VMware. Автор этого ресурса делает много интересных вещей, например, средство PowerShell OVF Helper.
OVF Helper - это репозиторий шаблонов для развертывания ВМ из виртуальных модулей (Virtual Appliances) в формате OVF, которые основаны на рабочем процессе развертывания в мастере создания машин vSphere Client. Через OVF Helper вы таким же образом соединяетесь с vCenter Server, заполняете нужные переменные и выполняете сценарий развертывания. Это точно так же просто, как и при использовании vSphere Client, но плюс в том, что вы можете использовать этот сценарий повторно, не проходя вручную шаги мастера клиента vSphere.
Также настроенные параметры в скрипте будут вам отличным напоминанием о том, какую конфигурацию вы использовали для виртуальных модулей.
На данный момент доступны сценарии для следующих продуктов и их версий:
Также на странице PowerShell OVF Helper размещены ссылки на OVA-модули, которые рекомендуется использовать совместно с соответствующей версией сценария.
Кстати, обратите внимание на раздел Tools на сайте автора - там много чего интересного:
Компания VMware объявила о первом релизе PowerCLI в этом году - на днях стала доступна для загрузки версия PowerCLI 12.5. Напомним, что о прошлой версии этого фреймворка для управления виртуальной инфраструктурой с помощью сценариев мы писали вот тут.
Давайте посмотрим, что там появилось нового:
1. Функции vCenter Server Appliance Service Management
Теперь PowerCLI поддерживает обращение к онпремизной инфраструктуре AWS, которая называется Outpost (стала доступной в конце прошлого года). Для этого есть командлет Get-VmcOutpost, который позволяет получить список доступных аутпостов для организации в VMC. Также при создании SDDC с помощью командлета New-VmcSddc есть параметр -Outpost, который позволяет создать объект в рамках аутпоста.
3. Поддержка Hot add / Remove для процессоров и памяти
Теперь есть новые параметры, в командлетах создания и настройки ВМ (Set-VM и New-VM), которые позволяют включить функции горячего добавления памяти и процессоров, а также удаления процессоров. Вот эти параметры:
-CpuHotAddEnabled (включить CPU Hot Add)
-CpuHotRemoveEnabled (включить CPU Hot Remove)
-MemoryHotAddEnabled (включить Memory Hot Add)
4. Включение шифрованной миграции vMotion
Теперь для командлетов создания и настройки ВМ (Set-VM и New-VM) есть параметр -MigrationEncryption, который позволяет включить шифрованную миграцию.
5. Обновления для Horizon 8.4
Модуль Horizon был обновлен и теперь включает в себя байндинги для Horizon 8.4 API.
Больше информации о новом релизе вы можете узнать вот тут. Скачать VMware PowerCLI 12.5 можно по этой ссылке.
Компания VMware объявила о выпуске новой версии Photon OS 4.0 rev 2. Напомним, что четвертая версия этой ОС, на базе которой построены виртуальные модули (Virtual Appliances) VMware, вышла в марте прошлого года.
Давайте посмотрим, что нового появилось в этом обновлении:
Поддержка OpenSSL 3.0 - теперь этот протокол используется по умолчанию
Новая утилита pmd-nextgen (photon management daemon), которая дает следующие возможности:
Удаленное управление системой с поддержкой мобильных устройств
Управление сервисами systemd и другими аспектами Photon OS через REST API
Использование REST API для конфигураций в реальном времени и тюнинга производительности, а также мониторинга состояния Linux-систем
Доработки движка реального времени:
Улучшения при работе с низкими задержками (low-latency), а также уменьшение джиттера (OS jitter)
Повышение стабильности работы и улучшения средств отладки
Прочие улучшения:
Доработки и багофиксы в tdnf
Поддержка GNU tarfs для ядра Linux-esx
Поддержка eBPF для ядра Linux
Улучшения установщика, такие как поддержка устройства Secondary Kickstart и пользовательских настроек монтирования устройств
Обновления пакетов:
Linux kernel 5.10.83
Glibc 2.32
Systemd 247.10
Python3 3.10.0
Openjdk : 11.0.9
Openssl : 3.0.0
Cloud-init: 21.4
Скачать Photon OS 4.0 rev 2 можно в ISO-дистрибутивах для платформ x86_64 и arm64, а также в формате OVA как виртуальный модуль для платформы VMware vSphere. Там же доступны кастомизированные образы Amazon AMI, Google GCE, Azure VHD, а также образ для Raspberry Pi.
Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).
Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.
Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.
Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:
Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:
Состав оборудования и особенности тестирования:
8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.
Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.
Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):
Визуализация результатов при изменении числа узлов:
В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:
В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:
Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.
В конце лета прошлого года мы писали об интереснейшем документе "VMware vSphere Snapshots: Performance and Best Practices", который содержит весьма полезную многим администраторам информацию о производительности снапшотов, а также лучшие практики по обращению с ними. Мы, кстати, часто пишем про это (1, 2, 3), и хорошо, что теперь об этом есть и подробный документ с картинками.
В конце года VMware решила обновить этот whitepaper, добавив туда немного информации о производительности снапшотов в инфраструктуре контейнеризованных приложений Kubernetes на платформе vSphere.
Тестовая конфигурация там выглядела вот так:
Соответственно, процедура тестирования выглядела так:
Снимаем базовый уровень производительности для ВМ worker-ноды без снапшотов под нагрузкой
Создаем снапшот ВМ worker-ноды
Запускаем бенчмарк и получаем данные о производительности
Увеличиваем по одному число снапшотов и повторяем цикл тестирования
Тестировались приложения Weathervane и Redis. Результаты показали, что даже при большом количестве снапшотов производительность не падает:
Компания VMware выпустила интересный документ "Intel architecture optimizes VMware SD-WAN Edge performance", в котором рассказывается о решении VMware Secure Access Service Edge (SASE) на базе аппаратных платформ Intel. Решение SASE объединяет компоненты интегрированной среды VMware, предназначенные для создания распределенной инфраструктуры безопасного и производительного доступа пользователей к приложениям и средства контроля этой активности.
Экосистема решения, описанного в документе, выглядит следующим образом:
Идея концепции SASE в том, чтобы обеспечивать защиту доступа к приложениям в географических центрах, максимально приближенных к облачной инфраструктуре, где эти приложения находятся (публичные облака и облака сервис-провайдеров). Сейчас у SASE есть более, чем 150 точек присутствия (points of presence, PoP), где физически размещено оборудование в облачных датацентрах, что позволяет построить безопасный и высокопроизводительный мост к SaaS-сервисам приложений.
Компоненты SASE включают в себя следующие решения:
Облачную технологию VMware SD-WAN, которая виртуализует WAN-сети в целях отделения программных служб от оборудования, что дает гибкость, простоту управления, производительность, безопасность и возможность быстрого масштабирования в облаках.
Компонент VMware Secure Access для удаленного доступа в рамках фреймворка zero-trust network access (ZTNA). Это новый уровень VPN-решений, который дает новые инструменты для доступа к облачным приложениям.
VMware Cloud Web Security - это интегрированное решение на базе таких техник, как Secure Web Gateway (SWG), cloud access security broker (CASB), data loss prevention (DLP), URL filtering, а также remote browser isolation (RBI), что реализовано на уровне SASE PoP для защиты прямого доступа к SaaS-приложениям и веб-сайтам.
VMware Edge Network Intelligence - это платформа для отслеживания активности подключений и сетевых потоков в рамках концепции AIOps, которая предполагает использование алгоритмов AI/ML для аналитики трафика WAN-to-branch, WiFi/LAN, а также на уровне приложений.
В документе описывается использование компонентов VMware SD-WAN Edge на базе различных платформ Intel, использующих процессоры Atom и Xeon. Требуемая конфигурация устройств SD-WAN рассматривается через призму требований приложений к пропускной способности канала, а также объема виртуализуемых сетевых служб, таких как фаерволы, системы IDS и прочее, которые работают как VNF (virtual network functions) в рамках программно-аппаратных модулей.
Недавно мы писали об уязвимости Log4j, затрагивающей компоненты веб-серверов Apache Software Foundation log4j Java logging, а значит присутствующей и во многих продуктах VMware. Также мы рассказывали о том, как понять, что вас сканируют на уязвимость log4j, если у вас есть VMware vRealize Network Insight.
Надо сказать, что у партнеров VMware есть такое средство, как HealthAnalyzer, которое осуществляет сбор данных с различных компонентов виртуальной среды и составляет отчет об их состоянии. Оно позволяет собрать детальную информацию о продуктах VMware Horizon, VMware vSphere и VMware NSX, которая включает в себя различные конфигурации и данные об использовании. Собранные с помощью VMware HealthAnalyzer Collector данные можно отправить партнерам VMware или в саму VMware для дальнейшего анализа.
HealthAnalyzer позволит вам обнаружить угрозы, которые описаны в статьях CVE-2021-4428, CVE-2021-45046 и CVE-2021-45105 (а это 10/10 и 7.5/10 по шкале серьезности). Однако чтобы это работало, вам нужно удалить старую версию VMware HealthAnalyzer и поставить новую с портала Partner Connect.
Чтобы удалить старую Java-версию HealthAnalyzer, нужно просто удалить ее папки и связанные файлы. Для виртуальных модулей - нужно выключить ВМ и удалить ее из инвентори.
Также если вы будете использовать предыдущую версию анализатора, то ваши регистрационные данные в форме не будут приняты:
За установкой продукта HealthAnalyzer обращайтесь к своему поставщику VMware.
Ну и бонус-видео о том, как временно обезопасить свой VMware vCenter от Log4j, пока критические фиксы еще в пути:
Компания VMware анонсировала новую версию продукта VMware HCX 4.3, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о возможностях версии 4.2 этого продукта мы писали вот тут.
Давайте посмотрим на новые возможности HCX 4.3:
1. Переход на PostgreSQL
Теперь HCX использует БД PostgreSQL вместо устаревших баз данных, использовавшихся ранее. Для пользователя переход произойдет незаметно, а сами данные в фоновом режиме будут перенесены на новую платформу.
2. Улучшения HCX Network Extension
Теперь для виртуальных модулей Network Extension появились функции высокой доступности (high availability). Так как сервис Network Extension является критичной частью HCX, нарушения в работе которого могут привести к серьезным проблемам с функционированием, то теперь на уровне виртуальных модулей (Virtual Appliance) есть функции HA, которые работают в режиме active/standby. В случае сбоя переключение на запасной узел происходит автоматически.
Диаграмма ниже показывает, как работают виртуальные модули NE, которые формируют пары на каждой из площадок, а во время нормальных операций трафик использует active-туннель между модулями. Другой туннель между standby-модулями также поддерживается, но трафик по нему не идет. На него происходит переключение в случае сбоя основного канала.
HA group 1 и HA group 2 имеют независимые механизмы хартбитов, чтобы мониторить состояние виртуальных модулей.
3. Улучшения OS Assisted-миграций
OS Assisted Migration (OSAM) - это режим миграции виртуальных машин из не-vSphere окружений, таких как KVM и Hyper-V, на платформу vSphere. Здесь было сделано несколько важных улучшений:
Поддержка новых гостевых ОС - теперь HCX поддерживает миграцию ВМ на базе RHEL 8.x (64-bit) и CentOS 8.x (64-bit) в окружениях KVM на vSphere. Кроме того, можно мигрировать RHEL 8.x (BIOS/GEN-1 & UEFI/GEN-2) и CentOS 8.x (BIOS/GEN-1 & UEFI/GEN-2) из виртуальных машин Hyper-V.
Совместимость HCX OSAM для vSphere и Cloud Director - теперь при миграции поддерживается связка продуктов VMware vSphere 7.0 U3 и VMware Cloud Director 7.0 U3.
4. Улучшения юзабилити
Устранен лимит на 15 символов для имен хостов ВМ на базе MS Windows при кастомизации гостевой ОС.
Возможность изменять Compute Profile в режиме OSAM. Ранее надо было явно указывать целевой датастор в профиле, теперь же HCX обнаруживает набор датасторов, которые доступны для репликации в кластер. Также происходит валидация, что Sentinel Data Receiver (SDR) имеет доступ к датастору, указанному пользователем.
Более подробно о продукте VMware HCX 4.3 можно почитать на этой странице.
Начиная с 25 ноября, провайдеры получили доступ к VMware Tanzu Standard - платформе, которая позволяет разработчикам развертывать и поддерживать свою инфраструктуру контейнеризованных приложений в кластерах Kubernetes. Теперь это возможно и в облаке посредством интеграции решений VMware Tanzu Standard и VMware Cloud Director (пока поддерживается версия 10.2), что позволяет создать инфраструктуру Kubernetes as-a-Service (KaaS) для мультиоблачных сред.
Теперь сервис-провайдеры имеют выбор между инфраструктурой Tanzu Kubernetes Grid, построенной на собственном дистрибутиве Kubernetes от VMware, и полностью интегрированном сервисе на платформе vSphere. Управлять всем этим можно через консоль Tanzu Mission Control.
Вот какие сервисы теперь могут предлагать провайдеры своим клиентам:
Создание кластеров K8s
Развертывание кластеров
Служба VMware Storage service для окружений разработчиков
Библиотека контента (Content library) для версий Kubernetes
Сетевой сервис для K8s-кластеров, включая балансировку нагрузки (NSX ALB Basic), сервисы NAT и другое
Плагин для интерфейса Antrea Container Networking Interface (CNI)
Сервисы обслуживания жизненного цикла через Cluster API
Операции с кластерами K8s
Привязка и управление CNCF-совместимыми кластерами K8s
Компания VMware объявила о выпуске технологического превью продукта Application Transformer for VMware Tanzu, который позволяет еще больше сократить разрыв между виртуализацией на уровне контейнеров и инфраструктурой серверной виртуализации.
Теперь с помощью этого решения можно упростить имплементацию стратегии 5R для модернизации корпоративных приложений: rehost, replatform, refactor, retain, retire. Начать можно с концепции replatform, которая предполагает миграцию приложений в корпоративную среду контейнеров, которая делает прозрачным и более гибким процесс развертывания и эксплуатации различных сервисов.
Application Transformer for Tanzu предназначен для решения следующих задач, касающихся legacy-приложений:
Discovery – утилита сканирует виртуальные машины, собирая структуру директорий, пулов ресурсов, имена приложений и процессов. Далее на основе этого выстраивается топология приложений датацентра.
Analysis – на базе собранной детальной информации, с учетом имеющихся бизнес-требований, администраторы и менеджеры датацентра решают, каким приложениям надо мигрировать в контейнеры и в каком порядке.
Transform – Application Transformer for Tanzu создает OCI-compliant образы контейнеров для Linux-based приложений посредством простого мастера, также в процессе поддерживаются такие сервисы, как Oracle WebLogic Server и Apache Tomcat. Выходные артефакты Kubernetes, такие как YAML-файлы, позволяют пользователям быстро развертывать образы контейнеров в кластерах VMware Tanzu Kubernetes.
Application Transformer for Tanzu работает без агентов поддерживает множество типов приложений (в базе есть более 200 сигнатур) и глубокий анализ содержимого ВМ. В список входят не только большие корпоративные приложения, такие как WebLogic и Tomcat, но и разнообразные generic Java-приложения. Утилита может получить имя приложения, состав его процессов, размещение на диске и другое.
Сам продукт использует VMware vCenter API для получения доступа к ВМ на платформе vSphere или VMware Cloud on AWS. За счет интеграции с решением VMware vRealize Network Insight, Application Transformer for Tanzu может использовать диаграмму потоков vRealize Network Insight для автоматического создания end-to-end топологий, что важно для визуализации взаимосвязей приложений.
Далее, если администратор принял решение о переводе приложения в кластер Kubernetes, Application Transformer for Tanzu предоставляет процесс на базе мастера, который автоматизирует задачи контейнеризации, такие как создание docker-файлов, генерацию образов контейнеров, сохранение их в нужный репозиторий, а также создание YAML-манифестов Kubernetes для приложений на базе Linux. Затем, если нужно развернуть приложение, можно использовать команду Kubectl для пуша OCI-образа на платформу VMware Tanzu Kubernetes.
Вот какие основные премущества дает Application Transformer for Tanzu:
Holistic view – создание визуальных топологий через CLI/API, используя метаданные компонентов приложений и проанализированные связи между ними.
Efficiency through automation – уменьшение ручных операций за счет глубокой интроспекции в ВМ, создания инвентаря объектов и маппинга ВМ в рамках топологий.
Flexibility – Application Transformer for Tanzu позволяет пользователям выбрать действия в рамках R-фреймворка на базе скоринга приложений.
Increased agility and speed to market – Application Transformer for Tanzu уменьшает время и уменьшает затраченные ресурсы на модернизацию старых приложений, которых в больших компаниях довольно много. Также утилита уменьшает и время на ввод в эксплуатацию старых и новых приложений в унифицированную среду контейнеров.
Более подробно о VMware Application Transformer for Tanzu можно почитать на странице продукта. Application Transformer for VMware Tanzu доступен как для облачной инфраструктуры VMware Cloud on AWS, так и для онпремизной VMware vSphere. Для системных интеграторов будет доступен бесплатный NFR-ключ.
Сегодня мы поговорим об улучшениях в плане производительности платформы VMware vSphere 7 Update 3, о которых рассказано в обновившемся недавно документе "What’s New in Performance for VMware vSphere 7?". О похожем документе о производительности платформы vSphere 7 Update 2 мы писали в начале осени тут.
Давайте посмотрим, что нового в vSphere 7 U3 в плане производительности:
1. Масштабируемость виртуальных машин
Теперь максимальные параметры ВМ, доступных в vSphere выглядят так:
2. Оптимизации рабочих нагрузок, чувствительных к задержкам
Гипервизор VMware ESXi был еще больше оптимизирован, чтобы быстрее исполнять приложения, чувствительные ко времени отклика и задержкам (ultra-low-latency applications), уменьшены jitter и interference для приложений реального времени. Для этого было сделано множество оптимизаций в плане обработки прерываний. Чтобы воспользоваться этой функцией (low-latency mode) ее надо включить в BIOS машины.
3. Технология vSphere Memory Monitoring and Remediation (vMMR)
Размер памяти DRAM влияет на 50-60% стоимости самого сервера. При этом 1TB DRAM - это уже 75% этой стоимости. Поэтому VMware давно борется с этим, и одна из возможных оптимизаций здесь - использование Intel Optane Persistent Memory Mode, когда железо использует DRAM как кэш и представляет PMem как основную память системы. PMem более дешевая технология, но имеет побольше задержки (latency).
С помощью vSphere Memory Monitoring and Remediation (vMMR) можно следить за работой памяти в режиме Intel PMem Memory Mode и получать алерты когда ESXi исчерпывает память DRAM, что может привести к падению производительности сервера.
4. NVMe over TCP/IP
В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании при поддержании высокого уровня производительности.
Недавно компания VMware провела тестирование баз данных PostgreSQL в качестве рабочей нагрузки в виртуальных машинах vSphere 7.0 U2 с использованием памяти Intel Optane DC persistent memory (PMem). Напомним, что именно на этот тип памяти компания VMware ориентируется при разработке технологии Project Capitola.
Память Intel Optane DC persistent memory (DCPMM она же PMEM) не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.
В качестве тестового стенда использовалась следующая конфигурация хоста ESXi и виртуальных машин:
Память PMEM была презентована виртуальным машинам как очень быстрое устройство хранения (NVDIMM). Конфигурация PostgreSQL была следующей:
VMware использовала 3 различных конфигурации для тестирования:
2 устройства NVME SSD (это базовый уровень) - оба раздела, WAL и база данных, были на двух разных быстрых SSD
WAL на базе PMEM - раздел WAL поместили на 200-гигабайтное устройство PMem NVDIMM
WAL и база данных на PMem - все разделы были размещены на устройствах PMem NVDIMM
В виртуальной машине запускали стресс-тест базы данных со значительной нагрузкой на диск, средней нагрузкой на систему и интегрированными транзакциями. Пропускная способность (throughput) измерялась в количестве транзакций в секунду (TPS).
Вот что из этого вышло:
По итогу теста для полной нагрузки на PMEM по сравнению с SSD пропускная способность выросла на 44.6%, а задержка (latency) упала на 30.8% (при перенесении только WAL на PMEM эти показатели составили 13.4% и 11.8%, соответственно).
Те же самые параметры для read-only транзакций:
Тут уже разница более, чем в 3 раза. Также VMware попробовала машину с 1 ГБ оперативной памяти вместо 200 ГБ - там улучшение было еще больше, а среднем PMEM дает улучшение производительности по сравнению с SSD в районе 4.5x.
Полное описание процедуры тестирования находится тут.
Компания VMware выпустила интересный плакат, который может быть полезен Enterprise-администраторам, использующим в своей компании гибридную среду с применением публичного облака VMware Cloud on AWS. В постере AWS Logical Design Poster for Workload Mobility рассказано о том, какими способами можно перенести рабочие нагрузки собственного датацентра в облачную среду VMConAWS (например, с помощью решения VMware HCX), а также, каким образом организовать сетевой сопряжение компонентов гибридной среды.
Постер состоит из 5 основных секций, давайте рассмотрим их несколько подробнее:
On-Premises Datacenter – это собственная виртуальная инфраструктура предприятия, которая может содержать в себе различные типы сетей и хранилищ. В ней должна работать платформа vSphere не ниже версии 6.0 и решение HCX для миграции рабочих нагрузок.
Amazon Web Services - организации заводят себе учетную запись AWS VPC, которая работает со службой VMware Cloud on AWS. Можно иметь несколько сред AWS VPC, но только одна может быть соединена с VMConAWS. Другие VPC соединяются с VMware Cloud on AWS через VMware Transit Connect и AWS Transit Gateway.
VMware Cloud on AWS - объект Software-Defined Data Center (SDDC) использует архитектуру VMware Cloud Foundation (VCF) и включает в себя решение VMware HCX для переноса онпремизных нагрузок в облачную среду (это аддон к VMConAWS). Можно использовать несколько SDDC в составе группы. При включении VMware HCX его компоненты автоматически развертываются в облаке. Как только будет настроено соединение между собственным датацетром и VMware Cloud on AWS, организация сразу может приступить к настройке HCX и миграции виртуальных машин в публичное облако.
Network Connectivity Options - компании могут выбрать из нескольких вариантов сетевых соединений между собственным датацентром и облачным, в зависимости от имеющейся сетевой инфраструктуры и типа соединения с удаленным датацентром.
Workload Migration Steps Using VMware HCX – в этом разделе указан список шагов, которые нужно предпринять при миграции ВМ в облако с помощью HCX. Там есть кликабельные ссылки для получения детальной информации, например, об используемых портах и соединениях, а также методах миграции, которые использует HCX.
Скачать VMware Cloud on AWS Logical Design Poster for Workload Mobility в размере плаката можно по этой ссылке.
На прошедшей онлайн-конференции VMworld 2021 компания VMware представила много новых интересных инициатив, продуктов и технологий. О некоторых из них мы уже рассказали в наших статьях:
Сегодня же мы поговорим о новом начинании VMware - Project Capitola. На рынке серверной виртуализации уже довольно давно развивается экосистема оперативной памяти различных уровней - стандартная DRAM, технология SCM (Optane и Z-SSD), модули памяти CXL, память PMEM, а также NVMe. По аналогии с сетевой инфраструктурой, где есть решение NSX для виртуализации и агрегации сетей, серверной инфраструктурой (где виртуализацией CPU занимается платформа vSphere) и инфраструктурой виртуализации хранилищ vSAN, компания VMware представила среду агрегации и виртуализации оперативной памяти - Project Capitola.
Это - так называемая Software-Defined Memory, определяемая в облаке (неважно - публичном или онпремизном) на уровне кластеров VMware vSphere под управлением vCenter:
Вся доступная память серверов виртуализации в кластере агрегируется в единый пул памяти архитектуры non-uniform memory architecture (NUMA) и разбивается на ярусы (tiers), в зависимости от характеристик производительности, которые определяются категорией железа (price /performance points), предоставляющей ресурсы RAM.
Все это позволяет динамически выделять память виртуальным машинам в рамках политик, созданных для соответствующих ярусов. Для Capitola обеспечивается поддержка большинства механизмов динамической оптимизации виртуального датацентра, таких как Distributed Resource Scheduler (DRS).
Вводить в эксплуатацию свои решения в рамках проекта Capitola компания VMware будет поэтапно: сначала появится управление памятью на уровне отдельных серверов ESXi, а потом уже на уровне кластера.
Очевидно, что такая технология требует поддержки на аппаратном уровне - и VMware уже заручилась поддержкой некоторых вендоров. В плане производителей памяти будет развиваться сотрудничество с Intel, Micron, Samsung, также будут интеграции с производителями серверов (например, Dell, HPE, Lenovo, Cisco), а также сервис-провайдерами (такими как Equinix).
Главная часть сотрудничества VMware - это взаимодействие с компанией Intel, которая предоставляет такие технологии, как Intel Optane PMem на платформах Intel Xeon.
Для получения подробностей смотрите следующие сессии с прошедшего VMworld 2021 (найти их можно тут):
[MCL2384] Big Memory – An Industry Perspective on Customer Pain Points and Potential Solutions
[MCL1453] Introducing VMware’s Project Capitola: Unbounding the "Memory Bound"
Ну а если вам хочется узнать больше о работе с памятью платформы vSphere в принципе, то есть еще и вот такие сессии:
How vSphere Will Redefine Infrastructure to Run Future Apps in the Multi-Cloud Era [MCL2500]
The Big Memory Transformation [VI2342]
Prepared for the New Memory Technology in Next Year’s Enterprise Servers? [VI2334]
Bring Intel PMem into the Mainstream with Memory Monitoring and Remediation [MCL3014S]
60 Minutes of Non-Uniform Memory Access (NUMA) 3rd Edition [MCL1853]
Chasing Down the Next Bottleneck – Accelerating Your Hybrid Cloud [MCL2857S]
Implementing HA for SAP HANA with PMem on vSphere 7.0U2 [VI2331]
5 Key Elements of an Effective Multi-Cloud Platform for Data and Analytics [MCL1594]
Будем держать вас в курсе о дальнейших анонсах инициативы Project Capitola компании VMware.
Компания VMware выпустила обновление главного фреймворка для управления виртуальной инфраструктурой с помощью командных сценариев - PowerCLI 12.4. Напомним, что в прошлый раз об обновлении этой платформы мы писали вот тут. В обновленной версии PowerCLI появилось несколько новых возможностей:
1. Новый API интерфейс - RestAPI
Раньше PowerCLI имел 2 основных пути коммуникации с vSphere API:
Get-View (SOAP API bindings)
Get-CISService (JSON-RPC)
Теперь новые PowerCLI API байндинги позволяют работать vSphere REST API и предоставляют практически нативный интерфейс PowerShell.
Модуль, реализующий эти функции, называется vSphere Automation API SDK. Чтобы начать использовать новые возможности через автоматизацию REST API, нужно скачать новую версию PowerCLI - пакет будет называться "VMware.Sdk.vSphere". Он содержит в себе субмодули для взаимодействия со всеми REST API, которые есть в VMware vSphere.
В REST API есть методы для исполнения API и работы со структурами данных, которые используются как входные параметры для API. Новые API байндинги предоставляют низкоуровневые PowerShell функции для работы со всеми этими методами и структурами.
Функция Invoke используется для исполнения методов REST, таких как GET/PUT/POST и DELETE:
Функция Initialize используется для создания структуры данных, которая будет передана к REST API. Например, так выглядит создание структуры "локальный аккаунт":
Раздел документации vSphere API Documentation был существенно обновлен - туда были добавлены примеры, показывающие вызов REST API через PowerCLI. Например, вот раздел Create Local Accounts.
2. Новый vSphere Management Module
Для управления платформой vSphere теперь появился новый модуль. Это модуль на базе PowerShell, для построения которого используется архитектура модулей vSphere Automation API SDK, о которой рассказано выше. На данный момент в модуле 6 командлетов, позволяющих управлять сертификатами (по ссылкам вы можете почитать о них):
Когда вы работаете в дэшборде решения для комплексного управления и мониторинга виртуальной инфраструктуры VMware vRealize Operations Manager, управление действующими политиками происходит на вкладке Policies. Применяются эти политики последовательно в порядке приоритета, указанного в колонке Priority.
Если у вас больше одной активной политики, то вы можете открыть интерфейс изменения порядка политик, чтобы поменять их приоритет. Для этого нажимаем бокс с тремя точками и выбираем пункт Reorder Policies:
Далее политику можно перетащить вверх и вниз, чтобы изменить ее приоритет:
Приоритет политики по умолчанию всегда отмечен как D (Default Policy), остальные отмечаются цифрами 1,2,3 и т.п. Цифра 1 имеет наивысший приоритет применения политики. Если вы назначаете объект членом нескольких групп (Object Groups), а для каждой группы назначена своя политика, то vRealize Operations Manager назначает политику с наивысшим приоритетом для этого объекта.
Компания VMware к началу осени обновила один из самых главных своих документов - "Performance Best Practices for VMware vSphere 7.0, Update 2". Этот whitepaper не просто так называется книгой, так как данный документ представляет собой всеобъемлющее руководство почти на 100 страницах, где рассматриваются все аспекты поддержания и повышения производительности новой версии платформы VMware vSphere 7.0 Update 2 и виртуальных машин в контексте ее основных возможностей.
Глобальные разделы документа:
Hardware for Use with VMware vSphere - о том, какое оборудование и как работает с платформой
ESXi and Virtual Machines - об оптимизации хостов и ВМ на них
Guest Operating Systems - об оптимизации непосредственно гостевых операционных систем
Virtual Infrastructure Management - лучшие практики для средств управления виртуальной инфраструктурой
Ну а подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках.
Очень полезное руководство для тех, кто хочет выжать из своей виртуальной среды максимум. Скачать книгу Performance Best Practices for VMware vSphere 7.0, Update 2 можно по этой ссылке.
В последнее время в продуктах VMware часто находят различные уязвимости, а хакеры по всему миру разрабатывают различные руткиты и утилиты для взлома инфраструктуры VMware vSphere и серверов ESXi. В связи с этим многие администраторы хотели бы отключить неиспользуемые плагины, которые есть в VMware vCenter. Совсем недавно появились следующие оповещения о проблемах с безопасностью (VMware Security Advisories, VMSA), которые касаются плагинов:
CVE-2021-21985 - VMSA-2021-0010 (плагин Virtual SAN Health Check)
CVE-2021-21986 - VMSA-2021-0010 (плагины Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager и VMware Cloud Director Availability)
Подробно об отключении плагинов у VMware написано в KB 83829. Приведем здесь данную процедуру вкратце.
В конфигурационный файл на сервере vCenter вам нужно будет добавить одну или несколько следующих строчек, в зависимости от плагина, который вы хотите отключить:
Давайте теперь посмотрим, какие плагины включены по умолчанию на всех серверах vCenter после установки (Default), а какие устанавливаются и включаются только после установки соответствующего продукта (Product):
vCenter Version
vRealize Operations
vSAN
VMware vSphere Lifecycle Manager
Site Recovery
VMware Cloud Director Availability
6.5
Default
Default
N/A
Product
Product
6.7
Default
Default
N/A
Product
Product
7.0
Default
Default
Default
Product
Default
Итак, чтобы отключить плагины, вам нужно:
Подключиться к серверу vCenter Server Appliance (vCSA) по SSH как root
Сделать резервную копию файла, например, командой: cp -v /etc/vmware/vsphere-ui/compatibility-matrix.xml /etc/vmware/vsphere-ui/compatibility-matrix.xml.backup
Открыть этот файл в текстовом редакторе командой: vi /etc/vmware/vsphere-ui/compatibility-matrix.xml
Добавить туда соответствующую строчку конфигурации из таблицы выше вот в этом месте (раздел pluginsCompatibility):